Refresh Babel discovery in the background and cache status health - #56

claude review: Reviewed 57e92bc: no issues found.

What I checked:

• Background refresh: discovery builds a complete BabelReleases snapshot and publishes it with no await between the writes. A failed or timed-out discovery keeps the previous snapshot, sets refresh_error, and retries after 30 s. Resolving the default release can't fail after a successful discovery (the constructor rejects an unavailable default), so nothing outside the try can end the refresh loop.
• Request pinning: each handler resolves its release once (handlers/base.py) and threads release.search_indices through get_normalized_nodes → _lookup_curie_metadata → _lookup_equivalent_identifiers and generate_setid. The elasticsearch.indices fallback is never reached from those handlers, so a refresh mid-request can't mix releases.
• Health cache: one shared, cancellation-shielded probe with 5 s / 1 s TTLs and a 3 s deadline. The probe's filter_path (*.mappings._meta.src.nodenorm) covers everything get_babel_version reads, and the cache is rebuilt when the default release changes.
• Target selection: _discover_babel_releases uses the same index-then-alias logic as the startup _validate_elasticsearch_index.
• Tests: 244 pass with outbound network blocked. The 4 live-Elasticsearch handler tests (test_set_identifiers, test_normalized_nodes) fail identically at the base commit, so they depend on the environment rather than this change.